The Internet Protocol (IP) has become the dominant transport protocol in both wireline and wireless networks, which has led to the convergence of telecommunication and data networks. In many services and applications (e.g., Voice over IP (VoIP), interactive games, instant messaging, etc.), the payload of an IP packet is almost of the same size or even smaller than the header. In addition to the IP network protocol, other protocols (e.g., real-time protocol (RTP), user datagram protocol (UDP), etc.) are added to the original information bits for effective transport in a packet data network.
Fortunately, it is not necessary to send the enormous RTP/UDP/IP header for each packet all the time. Instead a header compression algorithm such as the robust header compression (RoHC) may be used. The principle behind header compression is that most of the fields in the RTP/UDP/IP header are static; hence they can be sent once uncompressed during a first communication (e.g., the initial transmitted packets in a wireless system) from the compressor at the transmission side to the decompressor at the reception side. Once the decompressor has reliably acquired the static information, the compressor starts sending compressed headers carrying information regarding the dynamic parts of the header. From the compressed header, the decompressor is able to fully reconstruct the RTP/UDP/IP header and pass the packet on. In this way, the large headers are not transmitted for each packet, leading to tremendous savings in capacity.
However, current header compression schemes do have some drawbacks. For ease of explanation, these drawbacks will be described with respect to header compression implemented in a conventional wireless communication system.
FIG. 1 illustrates a general architecture of a well-known wireless communication network. As shown, an access terminal (AT) 10 communicates with a base station (BTS) 12 over an air interface. Examples of an AT include a mobile station, a mobile unit, a wireless phone, wireless equipped PDA or computer, etc. Multiple base stations 12 communicate with a radio network controller (RNC) 14, which provides signaling and traffic processing for each wireless data session. FIG. 1 shows the AT 10, BTS 12, RNC 14 and the interfaces between these components form what is known as a radio access network (RAN). The RAN communicates with a core network to access, for example, the internet. In the example of FIG. 1, the core network includes one or more packet data service nodes (PDSNs) 16 connected between the RNCs 14 and, for example, the internet (not shown).
As examples, header compression may occur between the AT 10 and the PDSN 16, between the AT 10 and the RNC 14, etc. When the AT 10 establishes a connection with the network, for example, a VoIP call, the application layer packet will be carried over the RTP/UDP/IP protocol stacks. The RTP/UDP/IP headers will be compressed by a compressor at the AT 10 using, for example, the RoHC algorithm mentioned above. The compressed packet will be sent uplink from the BTS 12 to the RNC 14 and from the RNC 14 to the PDSN 16. The decompressor at the RNC 14 or the PDSN 16 decompresses the RoHC header to re-establish the RTP/UDP/IP header. Similarly, on the downlink direction, the PDSN 16 and RNC 14 receive packets and the compressor at the PDSN 16 or RNC 14 compresses the RTP/UDP/IP headers to generate the RoHC or compressed header. The packet with compressed header is sent to the BTS 12 and on to the AT 10. A decompressor at the AT 10 decompresses the RoHC header to obtain the original RTP/UDP/IP header, and passes the packet onto the application layer.
FIG. 2 illustrates another architecture of a wireless communication network—the so called flat IP network architecture. As shown, the AT 10 communicates with a base station (BS) 20 over an air interface. The BS 20 converges multiple mobile network elements into a single entity and combines the signaling and bearer into one IP connection. In this flat IP architecture, the BS 20 contains all the radio access technology based functionalities. In other words, the functionalities in BTS, RNC and PDSN of FIG. 1 are be converged to the BS. The BS 20 functions like a router in the network and communicates with other BSs and network elements. Compared to FIG. 1, there are no separate RNC and PDSN elements anymore. The BS may also communicate with an access gateway 22, which provides for external connection to other networks such as the internet.
In the architecture of FIG. 2, header compression may occur between the AT 10 and the BS 20, or between the AT 10 and the access gateway 22. When the AT 10 establishes a connection with the network, for example, a VoIP call, the application layer packet will be carried over the RTP/UDP/IP protocol stacks. The RTP/UDP/IP headers will be compressed by a compressor at the AT 10 using, for example, the RoHC algorithm mentioned above. The compressed packet will be sent uplink from the AT 10 to the BS 20, or from the AT 10 to the BS 20 and from the BS 20 to the access gateway 22. The decompressor at the BS 20 or the access gateway 22 decompresses the RoHC header to re-establish the RTP/UDP/IP header. Similarly, on the downlink direction, the access gateway 22 and BS 20 receive packets, and the compressor at the access gateway 22 or the BS 22 compresses the RTP/UDP/IP headers to generate the RoHC or compressed header. The packet with the compressed header is sent to the AT 10. A decompressor at the AT 10 decompresses the RoHC header to obtain the original RTP/UDP/IP header, and passes the packet onto the application layer.
The robust header compression (RoHC) algorithm uses several encoding methods, including the window-based least significant bits encoding algorithm, for the compression of the dynamic fields in the protocol headers. The RoHC compression algorithm also incorporates a feedback mechanism. The RoHC compression algorithm is very efficient on wireless links with high error rates and/or long round trip time. Because of its efficiency and robustness, the RoHC compression algorithm is suitable on wireless networks where the radio resource is costly.
When there are large consecutive packet losses in the link layer and/or a large degree of packets out of order, the decompressor is not able to decompress newly received packets. When decompression failure happens, the decompressor will loose its context. The context of a header compression session is the state of the compressor and the state of the decompressor, and these states must be synchronized for successful header reconstruction. The decompressor usually sends a feedback packet to the compressor instructing the compressor to resynchronize the compression status by sending the full header. The decompressor will discard received packets with the compressed header, including uncorrupted packets, until the full header information is received in an uncompressed packet. As a result, during resynchronization between the compressor and decompressor, additional packet losses will occur, degrading the performance and quality of the call. These packet losses caused by loss of synchronization between the compressor and decompressor should be minimized or eliminated.